DirectConnect 承諾・関連付けの待ち時間とblackhole対応

いわさです。

AWS Direct Connect(以後DX) のプライベート接続には "Direct Connectゲートウェイ(DXGW)タイプ" と "仮想プライベートゲートウェイ(VGW)タイプ" があります。

今回、VGWタイプからDXGWタイプへ回線の切り替えを行う機会がありました。

切り替えの手順の全体については触れませんが、今後同様の作業を行う際に手順の整理を事前に行う必要がある場合などに備えて、実際の数値は参考になるので記しておきたいと思います。

待ち時間が発生する操作がいくつかある

仮想インターフェース(VIF)承諾やVGW関連付けの作業を行っていくのですが、いくつかの操作で待ち時間が発生しました。
どの操作でどの程度の待ち時間が発生したのか、参考値と共に記載します。

※数値は今回切り替えた際の実測値です。切り替え時にこの時間で実施できることを保証するものではありません。参考値として考えていただければと思っています。

仮想インターフェースの承諾で3分

新しく払い出されたVIFを承認します。
VIFのステータスが"pending"になり、BGPステータスは"down"になります。

少したつとVIFのステータスが"available"になりますが、BGPステータスはしばらく"down"のままです。
もう少し待つとupになります。

今回はVIF承認開始からBGPステータスUPまで3分ほどでした。

旧VGWのデタッチに8分

今回の切り替えは新しくVGWを作成しておき、VPCから旧VGWをデタッチして新VGWをアタッチするという方法を行いました。
旧VGWのデタッチ完了までに8分ほどかかりました。
新VGWのアタッチは数秒で完了しました。

VGWとDXGWの関連付けに10分

DXGWとVGWの関連付けを行う際は完了までに10分ほどかかりました。
完了するとステータスが "associated" になります。

VGWをデタッチした際のルートテーブルの挙動

対象ルートがルート伝播済みの動的ルートの場合と静的ルートの場合で異なります。
静的ルートの場合は旧ルート情報が残るのでターゲットの変更または削除が必要です。

動的ルート

VGWデタッチ後はVGWへのルートは自動で削除されますので明示的な削除は不要です。

デタッチ前

デタッチ後

静的ルート

一方、VGWデタッチ後はVGWへのルートステータスが "blackhole" になります。
こちらはターゲットを新しいVGWへ変更する必要があります。

さいごに

待ち時間が数秒ではないので、中々ステータスがUPにならない状況に焦ってしまう場面がありました。
ある程度の待ち時間が発生することを認識しておくことで落ち着いて対処出来ると思いますので少し時間がかかるものだと知っておくと良いと思いました。